恢復時間目標 (RTO) 是您的企業在不造成重大財務損失的情況下可以容忍的最大停機時間。RTO 與恢復點目標 (RPO) 一起使用，或者您的企業可以從中斷造成的數據丟失中恢復的時間間隔。合理的 RTO 和 RPO 目標有助于在災難后更平穩地恢復到正常狀態，并且應該成為災難恢復計劃的一部分。

恢復時間目標 (RTO) 的定義

RTO 是災難發生后恢復業務和 IT 基礎設施所需的目標時間。例如，兩小時的 RTO 意味著您給負責人員兩個小時來重新恢復您的服務。數據恢復屬于 RTO 的范疇。

設置 RTO 時，您應確保它反映您業務的性質和狀態。例如，如果您的業務依賴于在線交易，那么停機時間過長可能會嚴重影響您的生存能力。因此，您的 RTO 應該足夠短，以盡量減少影響。在這種情況下，一個好的 RTO 是在一兩個小時（最多）內讓您的操作恢復正常。

相比之下，能夠負擔得起使用紙質訂單和人工開票運營一兩天的組織，在極端情況下也能夠承受 1 天或 2 天的 RTO，甚至一周的 RTO。

在某些情況下，由于自然災害導致您的基礎設施、您的服務提供商的基礎設施和您周圍的人的基礎設施癱瘓，長時間停機可能是不可避免的。如果您的企業無法承受此類停機時間，您可能需要花費更多資金來讓您的 IT 基礎設施為這些類型的災難做好準備。

一種選擇是將您的 IT 服務外包給更有信譽的提供商。不要放棄盡職調查以確保您獲得最有能力的供應商。與供應商協商以獲得最好的條款，并確保支持可用性、響應時間和解決時間在您的服務級別協議中規定。

您還可以根據中斷的嚴重程度設置不同的 RTO。例如，如果服務器崩潰，1 小時的 RTO 可能就足夠了。在自然災害等最壞情況下考慮更長的 RTO。

理想情況下，您的 RTO 不應超過最大時間點，在此時間點您的企業仍然可以承擔收入和其他損失而不會產生實質性的運營影響。您可能需要緩解措施來避免 RTO 失敗。測試這些過程應該是您的災難恢復計劃的一部分。

當災難襲來時，您的 IT 團隊在滿足 RTO 方面的表現可能取決于您的恢復程序。如果您的團隊計劃和排練良好，RTO 可能會更短或等于實際恢復時間 (RTA)，或者您的團隊從停機時間中恢復所需的實際時間。在這種情況下，祝賀您的團隊出色地完成了工作。

恢復點目標 (RPO) 的定義

RPO 是您在不顯著影響業務的情況下可以承受的丟失數據的最長時間。超過 RPO 的數據丟失可能對您的業務有害。例如，兩小時的 RPO 意味著您應該每小時安排一次備份，以便在停機時恢復數據。定義 RPO 有助于避免在您的任何應用程序出現故障時丟失任何數據。

計算 RPO 時，請考慮您的組織可以接受的數據丟失。不同的應用程序可能具有不同的 RPO，具體取決于它們對您的運營的重要性。數據備份包含在 RPO 中。

與 RTO 一樣，RPO 取決于您的業務性質。RPO 可能從接近零到 24 小時不等。接近零是出于監管目的需要維護數據完整性的大型企業的理想選擇。較長的 RPO 可能是小型企業的理想選擇，它們可以在不需要記錄的情況下運營長達一天。其他組織可以使用介于這些極端之間的 RPO。

在災難恢復計劃中設置數據備份過程時，RPO 是一個重要的考慮因素。例如，如果您的企業在災難來襲時無法承受丟失任何數據的后果，則可以包括用于數據備份和復制的云存儲解決方案。在這種情況下，即使發生數據丟失，它也會保持在最低限度，因為故障轉移策略會自動啟動。

對于數據要求不太嚴格的組織，數據備份可以包括定期和持續的生產快照。對于那些最多可以存在一天而沒有記錄的情況，外部存儲備份或傳統磁帶備份可能就足夠了。

在任何情況下，較短的 RPO 都會導致使用更昂貴的數據備份選項。無縫故障轉移和故障回復的成本高于生產快照和存儲備份。

設置災難恢復計劃時，請確保您的 RPO 反映了您對數據丟失的容忍度。在規劃災難恢復時，應同時考慮 RTO 和 RPO。

數據恢復過程應該是災難恢復演練的一部分。努力使實際恢復點 (RPA) 或恢復數據所需的實際時間短于或等于您的 RPO。如果 RPA 證明比你的 RPO 長，你可能需要修改你的災難恢復計劃。

RTO與RPO的異同

關于 RTO 和 RPO 的含義以及它們的組成可能有些混淆。讓我們通過展示這兩個概念之間的異同來澄清這一點。

首先，讓我們討論一下兩者的相似之處。

• RTO 和 RPO 都處理時間。RTO 處理災難后恢復業務和 IT 基礎設施所需的時間，而 RPO 則關注恢復中斷期間丟失的數據量所需的最長時間。
• RTO 和 RPO 失敗都可能導致重大的收入損失。管理層必須與 IT 協調，平衡兩者以將風險降至最低。
• OptimalRTO 和 RPO 分別需要 100% 的正常運行時間和零數據丟失。兩者都只能通過高可用性解決方案來實現，例如包含連續數據復制的故障轉移策略。

RTO和RPO也有區別。

• RTO 比 RPO 涵蓋的范圍更廣。在災難期間，RTO 會處理您的整個 IT 基礎設施。另一方面，RPO 只處理數據。因此，RTO 可能比 RPO 更昂貴。
• RTO 更為復雜，因為它可以使用范圍更廣的手動和自動化技術來恢復整個 IT 基礎架構。RPO 只需要定期自動備份數據。

如何計算 RTO 和 RPO

RTO 涉及您的應用程序和系統的整體。通常，RTO 會考慮 RPO，因為數據恢復是 RTO 的一部分。實現 RTO 的大部分成本可能用于 RPO。

計算 RTO 時考慮以下因素：

• 停電成本
• 系統重要性
• 恢復程序的復雜性
• 緩解成本

由于 RPO 只處理數據，因此比 RTO 更容易計算。如前所述，較短的 RPO 可能需要更多的時間和金錢。雖然更長的 RPO 可能更便宜，但您有丟失更多數據的風險。

計算 RPO 時，請考慮以下因素：

• 最大可容忍的數據丟失量
• 丟失數據給您的運營帶來的成本
• 緩解成本

在計算 RTO 和 RPO 時，貴組織的 IT 人員、財務資源和聲譽是其他考慮因素。必須對用戶、應用程序和系統進行調查，目的是了解系統及其中駐留的數據的重要性。

調查結束后，計算停機成本及其對收入和其他財務的影響，然后運行災難發生時發生的最壞情況。應不斷評估災難恢復計劃的整體有效性。在此期間，您還應該審查您的 RTO 和 RPO 的有效性并進行相應的修改。